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I. INTRODUCTION 



A. OBJECTIVE 

The purpose of this thesis is to design and implement a Microsoft Windows-based 
database system. This will significantly decrease the labor hours consumed in the 
generation of travel orders and travel claims within the Administrative Sciences 
Department at the Naval Postgraduate School. The manual system currently in place will 
be replaced by a single point data entry system in which repetitive tasks will be 
automated to the greatest extent possible. The practice of reentering data for each travel 
order and travel claim will be eliminated. The system will produce computerized reports 
which meet external reporting requirements while providing the ability to generate 
custom internal reports on an ad-hoc basis. The Microsoft Windows-based system will 
require minimal computer knowledge by the end-user. The application is written using 
OMNIS7 Integrated Development Environment and is implemented on a Microsoft 
Windows-based personal computer. 

Travel Database System is a Windows based application that allows the travel clerk 
to enter a complete record through the entry of multiple data fields in related windows. 
The application provides a method for retrieving, editing, deleting, inserting records. The 
system is tailored to produce the DD 1610, NAVPERS 1320 and the DD 1351. 
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B. TRAVEL DATABASE SYSTEM: AN OVERVIEW 

The Travel Database System (TDS) is developed to enhance the ability of the 
Administrative Sciences Department to automate the generation of travel orders and 
travel claims for both civilian and military personnel. To accomplish this goal a detailed 
analysis of the required input forms and output reports was conducted. From this the 
flow of information as well as the unique attributes associated with each was determined. 
The DD 1610, NAVPERS 1320 and the DD 1351 forms were used as the basis for the 
initial data structure. User requirements were determined through extensive interviews. 
The requirements were transformed into a prototype system which was demonstrated to 
the prospective end-users. To meet specific user requirements, the advanced features of 
the development environment were taken advantage of. 

The underlying structure of OMNIS7 eliminated the requirement of using common 
fields to create a link between objects. This system is developed using Blythe Software’s 
OMNIS7 Integrated Development Environment, version 1.03. 
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II. DEFINITION PHASE 



The first phase of an application development is to define what the project will do. 
The project may be to modify an existing application, develop a comprehensive set of 
applications around a common database, or automate a manual data related task. The 
definition can be determined by a team of experts working together or through a series 
of interviews or a combination of both of these. The scope of the project is determined 
during the definition phase (i.e. , what will be included as necessary functions as well as 
what would be extraneous functionality). The final function of the definition phase is 
determining the feasibility of the project. Feasibility includes cost, technical and 
schedule. [Ref 3: pg. 75] 

A. SCOPE OF THE PROJECT 

The goal of this project was to automate and track Temporary Additional Duty 
orders and travel claims generation. A determination was made that all work could be 
accomplished on a single IBM-compatible 386 computer operating under Microsoft 
Windows using 4mb RAM. The project was scheduled to run from March 92 to June 92. 
An extension until September 92 was granted due to the complexity of the OMNIS7 
Integrated Development Environment. System functionality requirements were determined 
during interviews with members of the Administrative Sciences Department as well as 
those members of the staff for whom the application was designed. 

o 

J 



The requirements which were agreed upon included the following: 

1 . Microsoft Windows based application developed using the OMN1S7 Integrated 
Development Environment 

2. A data structure was to be developed which would link the required reports to the 
personnel data file format. 

3. The on-screen editor would resemble the actual form as closely as possible. 

4. On-screen editing and updating of forms could be completed easily. 
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III. REQUIREMENTS PHASE 



The requirements phase is the one during which the determination is made of 
exactly what it is that the system will do. The goals of the system are delineated. The 
methods for determining the scope of the user’s requirements are varied. Interviews are 
sometimes ineffective as the users themselves do not have the knowledge to put forth 
pertinent questions. In this case it is up to the design team to sound the users for 
concepts of what it is they need. The design team may use a prototype which includes 
sample forms, reports and menus to give the end user an idea of the capabilities of the 
proposed system. [Ref. 3:pg 77] 

A. METHODOLOGY 

Interviews were conducted with the members of the Administrative Sciences 
Department for whom the application would be developed. The administrative assistant 
described functional requirements in great detail. The professors supervising the 
development provided the information related to the underlying data structure. 

The process of producing a prototype system from the initial requirements and its 
first version was reviewed by the supervising professor. Minor changes in the screen 
displays were requested. This process required just one iteration. The final version was 
delivered and deemed acceptable both by the end user and the supervising professor. The 
prototype was installed, allowing enough time for the developer to make minor changes 
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in structure and report format. An in depth tutorial for the end user was provided by the 
system developer. 

B. DATA REQUIREMENTS 

In a relational database structure the underlying entity is an object. In the OMNIS7 
Integrated Development Environment the individual objects are defined by file formats, 
as shown in Tables 1 through 5. It was determined that a total of four file formats would 
need to be developed. The formats which comprise the data structure of the TDS are 
PERSDATA.DF1 , DD1610.DF1, NP1320.DF1 and DD1351.DF1. The file formats are 
linked using the Record Sequencing Number (RSN) feature. 

The PERSDATA.DF1 file format is comprised of data and object properties, which 
comprise each personnel record in the personnel file. This is the information which is 
required for the personnel information portion of the DD forms 1610 and 1351 as well 
as the NAVPERS form 1320. The PERSDATA.DF1 represents the parent file format in 
the parent-child file format relationship as shown in Figure 1 . 
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PERSONNEL 




D0 1351 



Figure 1 . Relational Diagram 



The file format DD1610.DF1 is a child file format. This format has an optional 
Many(DD1610)-to-One(PERSDATA) relationship. The file format NP1320.DF1 is also 
a child of PERSDATA and shares the same relationship as the DD1610 file format. The 
DD1351.DF1 file format is a child of both the DD1610 and the NP1320 file formats. 
This file format shares an optional One-to-One relationship with it’s parent file formats. 
See Figure 2. 
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Figure 2. File Format Relationship 
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C. UPDATE, DISPLAY AND CONTROL MECHANISMS 



In order to complete the development of a database application the user-system 



interactions must be delineated. In the case of TDS this meant developing a plan for the 



user to make his/her way through a series of data display windows while manipulating 



the required data. (See Data Flow Diagrams depicted in Figures 3 and 4). 
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Figure 4. System Level Dataflow Diagram 



The data flow begins with a government traveler submitting a travel request form. 
The Administrative Assistant will open the Personnel Data Window and search the 
database for the member using either the member’s Social Security Number or the 
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member's Last Name. If the member is not in the database the member will be entered. 
If the member is in the database the record will be checked for validity and updated if 
required. If the member is in the Navy then the NAVPERS 1320 window is opened from 
within the Personnel Data Window. If the member is not in the military the DD1610 
Window is opened from within the Personnel Data Window. At this point all the data 
entry fields of the forms pertaining to Personnel Data are automatically filled in. The 
Administrative Assistant is then tasked with completing the form. The completed form 
is then printed out and delivered. 

In order to complete the DD form 1351, the user enters the database through the 
Personnel Data Window, finds the member, then opens either the DD 1610 window or 
the NAVPERS 1320 window whichever is appropriate. The travel order which 
corresponds to the requested DD1351 must be displayed on the screen. The user then 
selects DD 1351 and the data entry window is opened with all previously entered data 
automatically displayed. The administrative assistant then enters the remaining data, 
prints the report, and submits it to the appropriate office. 

The diagram depicted in Figure 5 is a representation of the menu hierarchy. In this 
database application the menu hierarchy is a direct representation of the underlying data 
structure. 
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Figure 5. Menu Hierarchy 



DATA DICTIONARY 
TABLE 1. DATA FILES 



FILE NAME 


TYPE 


DESCRIPTION 






PERSDATA . DF 1 


DATA 


ATTRIBUTES 


OF 


PERSONNEL DATA FILE 


DD1610.DF1 


DATA 


ATTRIBUTES 


OF 


DD 1610 




NP1320.DF1 


DATA 


ATTRIBUTES 


OF 


NAVPERS 


1320\B 


DD1351.DF1 


DATA 


ATTRIBUTES 


OF 


DD 1351 
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TABLE 2. FILE FORMAT PERSDATA.DF1 



Element 


-Type 


Width 


De script ion 


LAST_NAME 


Character 


15 IND 


last name 


FIRST_NAME 


Character 


15 IND 


first name 


MIDDLE_INITIAL 


Character 


1 


middle initial 


POSITION 


Character 


35 




SSN 


Character 


11 IND 




PHONE NUMBER 


Character 


13 




DEPARTMENT 


Character 


15 




CLEARANCE 


Character 


15 


Security clearance 


OFF_STA 


Character 


30 


Official Station 


ORG_ELE 


Character 


30 


Organizational Element 


TYPE_TRAVELER 


Character 


10 




DESIGNATOR 


Character 


4 




STREET_ADDRESS 


Character 


30 




CITY 


Character 


10 




STATE 


Character 


2 




ZIP_CODE 


Character 


5 




RANK_1 


Character 


6 




SERVICE_1 


Character 


6 




Record length is between 26 and 338 


bytes 




1000 records may use 


between 141000 


and 615000 


disk bytes 
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TABLE 3. FILE FORMAT DD1610.DF1 



Element 


Type 


Width 


Descr iot ion 


REQUEST_DATE 


Date 


D m Y 


Block 1 


PROCEED_DATE 


Date 


D m Y 


Block 10b 


PURPOSE 


Character 


280 


Block 9 


ITINERARY 


Character 


42 


Block 11 


RETURNED ATE 


Date 


D m Y 


Included in Block 


APPOX DAYS 


Character 


10 


Block 10a 


TYPE_ORDERS 


Character 


5 


Block 7 


VAR_AUTH 


Character 


1 


Included in 








Block 11 








Variation Author. 


COM_RAIL 


Character 


1 


Block 12 








Commercial Rail 


COM_AIR 


Character 


1 


Block 12 








Commercial Air 


COM_BUS 


Character 


1 


Block 12 








Commercial Bus 


COM_SHIP 


Character 


1 


Block 12 








Commercial Ship 


GOV_AIR 


Character 


1 


Block 12 








Government Air 
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TABLE 3, cont 



GOV VEH 



GOV SHIP 



RATE PER MILE 



ADV GOVT 



REIMBURS 



PER DIEM AUTH 



OTHER PER DIEM 



AS DET 



EST PER DIEM 



EST TRV COST 



EST OTHER 



EST TOTAL 



ADV AUTHORIZED 



REMARKS 



Character i 
Character i 
Number 2 dp 
Character l 
Character 1 
Character 1 
Character 1 
Character 1 



Number 2 dp 
Number 2 dp 
Number 2 dp 
Number 2 dp 
Character 5 
Character 420 



Block 12 

Government Vehicle 
Block 12 
Government Ship 
Block 12 
Rate Per Mile 
Block 12 
Advantage Gov't 
Block 12 
Reimbursement 
Block 13 

Per Diem Authorized 
Block 13 

Other Per Diem Rate 
Block 12 
Overseas travel 
only 

Block 14 

Estimated Per Diem 
Block 14 

Est. Travel Cost 
Block 14 
Other Expenses 
Block 14 
Estimated Total 
Block 14 

Advance Authorized 
Block 16 
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TABLE 3, cont 



REQ OFF 


Character 


30 


Block 17 

Requesting Officia. 


APP_OFF 


Character 


30 


Block 17 

Approving Official 


APP_SUB_1 


Character 


16 


Block 19 


APP_SUB_2 


Character 


16 


Appropriation 


APP_SUB_3 


Character 


16 


and Subhead 


OB J_CLASS_1 


Character 


4 


Block 19 


OBJ_CLASS_2 


Character 


4 


Object Class 


OBJ_CLASS_3 


Character 


4 




BUNO_l 


Character 


6 


Block 19 


BUNO_2 


Character 


6 


Bureau Control 


BUNO_3 


Character 


6 


Number 


SUB_AUTH_1 


Character 


3 


Block 19 


SUB_AUTH_2 


Character 


3 


Sub-auth 


SUB_AUTH_3 


Character 


3 




AUTH_ACCT_1 


Character 


8 


Block 19 


AUTH_ACCT_2 


Character 


8 


Authorizing 


AUTH_ACCT_3 


Character 


8 


Acct. Activity 


TYPE_1 


Character 


4 


Block 19 


TYPE_2 


Character 


4 


Type 


TYPE_3 


Character 


4 
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TABLE 3, cont 



TANGO_NO_l 


Character 


6 


Block 19 


TANGO_NO_2 


Character 


6 


Travel Ordei 


TANGO_NO_3 


Character 


6 


Number 


C0ST_C0DE_1 


Character 


15 


Block 19 


COST_CODE_2 


Character 


15 


Cost Code 


COST_CODE_3 


Character 


15 




ORD AUTH_OFF 


Character 


15 


Block 20 
Order 

Authorizing 

Official 


ISSUE_DATE 


Date 


D m Y 


Block 21 
Date Issued 


TRAVEL_ORD_NO 


Character 


20 IND 


Block 22 
Travel Ordei 



Number 



Record length is between 136 and 1720 bytes 

1000 records may use between 226000 and 2527000 disk bytes 
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TABLE 4. FILE FORMAT NP1320.DF1 



Element 


Type 


Width 




Descript ion 


FROM_l 


Character 


60 




Block 1 


STAN_DOC_NO 


Character 


12 IND 


Block 2 
Standard 
Document Number 


TANGO_NO 


Character 


12 




Block 4 


DATE 


Date 


D m 




Block 6 


REF_A 


Character 


40 




BLOCK 7 


INDIVIDUAL 


Character 


1 




BLOCK 8 

Individual 

Travel 


GROUP 


Character 


1 




BLOCK 8 
Group Travel 


PROCEED_ON 


Date 


D m 


Y 


Block 9 


AUTH_PROCEED 


Date 


D m 


Y 


Block 10 


APPROX_DAYS 


Character 


10 




Block 11 


EST_RE TURNED ATE 


Date 


D m 


Y 


BLOCK 12 


ITINERARY 


Character 


240 




Block 13 


TEMADD 


Character 


1 




BLOCK 14 
TEMADD 


TEMADDCON 


Character 


1 




BLOCK 14 
TEMADDCON 


TEMADDINS 


Character 


1 




Block 14 
TEMADDINS 


REASON 


Character 


120 




BLOCK 15 


AUTH__VISIT 


Character 


1 




Block 16 


APP SYM 1 


Character 


7 




Block 17 
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TABLE 4, cont 



APP_SYM_2 


Character 


7 


Appropriation 


APP_SYM_3 


Character 


7 


symbol 


SUB HEAD_1 


Character 


4 


Block 17 


SUB HEAD_2 


Character 


4 


Appropriation 


SUB_HEAD_3 


Character 


4 


Subhead 


OBJECT_l 


Character 


3 


Block 17 


OBJECT_2 


Character 


3 


Object Class 


OBJECT_3 


Character 


3 




BU_CONT_l 


Character 


4 


Block 17 


BU_CONT_2 


Character 


4 


BU CONT NUMBER 


BU_CONT_3 


Character 


4 




SUB_ALLOT_l 


Character 


5 


Block 17 


SUB_ALLOT_2 


Character 


5 


Sub-Allot 


SUB_ALLOT_3 


Character 


5 


Number 


AUTH_ACCTG_1 


Character 


6 


Block 17 


AUTH_ACCTG_2 


Character 


6 


Authorized 


AUTH ACCTG 3 


Character 


6 


ACCTG 

Activity 


TY_1 


Character 


2 


Block 17 


TY_2 


Character 


2 


TYPE 


TY_3 


Character 


2 




ACCTG_ACTY_1 


Character 


6 


Block 17 
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TABLE 4, cont 



ACCTG ACTY 2 


Character 


6 


PROPERTY 

ACCTGACTY 


ACCTG_ACTY_3 


Character 


6 




CC_1 


Character 


12 


Block 17 


CC_2 


Character 


12 


Cost Code 


CC_3 


Character 


12 




TRANSPORTATION 


Number 


2 dp 


Block 18 
Transportation 


PERDIEM 


Number 


2 dp 


Block 18 
Per Diem 


MISC_EXP 


Number 


2 dp 


Block 18 
Misc. Exp 


TOTAL_EXP 


Number 


2 dp 


Block 18 
Total 


CUST_I DECODE 


Character 


18 


Block 19 


ITEM 


Character 


120 


Block 20 


COMMENTS 


Character 


400 


Block 21 


AUTH_SIG 


Character 


40 


Block 23 


TRANS_REQUEST 


Character 


240 


Block 24 


COPY TO 


Character 


40 


Block 25 



Record length is between 122 and 1780 bytes 

1000 records may use between 199000 and 2598000 disk bytes 
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TABLE 5. FILE FORMAT DD1351.DF1 



Element Type Width Description 



PRIOR PAY Character 



DEP 1 


Date 


ARR 1 


Date 


DEP 2 


Date 


ARR 2 


Date 


DEP 3 


Date 


ARR 3 


Date 


DEP 4 


Date 


ARR 4 


Date 


DEP 5 


Date 


ARR 5 


Date 



DEP 6 


Date 




ARR 6 


Date 




DEP 7 


Date 




ARR_7 


Date 




TIME 1 


Short 


time 


TIME 2 


Short 


time 


TIME 3 


Short 


time 


TIME 4 


Short 


time 


TIME 5 


Short 


time 


TIME 6 


Short 


time 


TIME 7 


Short 


time 


TIME 8 


Short 


time 


TIME 9 


Short 


time 


TIME 10 


Short 


time 


TIME 11 


Short 


time 


TIME 12 


Short 


time 


TIME 13 


Short 


time 


TIME_14 


Short 


time 


PLACE 1 


Character 


PLACE 2 


Character 


PLACE 3 


Character 


PLACE 4 


Character 


PLACE 5 


Character 


PLACE 6 


Character 


PLACE 7 


Character 


PLACE 8 


Character 



40 Prior travel 
payments or 
advances under these 
orders 

D m Y Block 1: Dates 
D m Y 
D m Y 
D m Y 
D m Y 
D m Y 
D m Y 
D m Y 
D m Y 
D m Y 



D m Y 
D m Y 
D m Y 
D m Y 

Block 1: Times 



15 Block 1: Place 

15 

15 

15 

15 

15 

15 

15 
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TABLE 5, cont 



MODE_l 


Character 


2 


Block 1: 


Mode of 


MODE 2 


Character 


2 


travel 




MODE 3 


Character 


2 






MODE 4 


Character 


2 






MODE 5 


Character 


2 






MODE 6 


Character 


2 






MODE 7 


Character 


2 






STOP_l 


Character 


2 


Block 1: 


Reason 


STOP 2 


Character 


2 


for stop 




STOP 3 


Character 


2 






STOP 4 


Character 


2 






STOP 5 


Character 


2 






STOP 6 


Character 


2 






STOP 7 


Character 


2 







COL_l 


Number 


2 


dp 


Block 2: Cost of 


COL 2 
COL 3 
COL 4 
COL 5 
COL 6 
C0L_7 

MEALS_G_1 


Number 

Number 

Number 

Number 

Number 

Number 

Integer 


2 

2 

2 

2 

2 

2 

(0 


dp 

dp 

dp 

dp 

dp 

dp 

to 


lodging 

255) Block 3: 


MEALS G 2 


Integer 


(0 


to 


255) 


Meals\Govt 


MEALS G 3 


Integer 


(0 


to 


255 ) 




MEALS G 4 


Integer 


(0 


to 


255 ) 




MEALS G 5 


Integer 


(0 


to 


255) 




MEALS G 6 


Integer 


(0 


to 


255) 




MEALS_G_7 


Integer 


(0 


to 


255 ) 




MEALS_D_1 


Integer 


(0 


to 


255) 


Block 3: 


MEALS D 2 


Integer 


(0 


to 


255) 


Meals\Ded 


MEALS D 3 


Integer 


(0 


to 


255) 




MEALS D 4 


Integer 


(0 


to 


255) 




MEALS D 5 


Integer 


(0 


to 


255) 




MEALS D 6 


Integer 


(0 


to 


255) 




MEALS_D_7 


Integer 


(0 


to 


255 ) 




OM_l 


Integer 


(0 


to 


255 ) 


Block 3 : Open 


OM 2 


Integer 


(0 


to 


255) 


Mess 


OM_3 


Integer 


(0 


to 


255) 
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TABLE 5, cont. 



OM 4 


Integer 


( 0 to 


255) 


OM 5 


Integer 


( 0 to 


255 ) 


OM 6 


Integer 


( 0 to 


255 ) 


OM_7 


Integer 


( 0 to 


255 ) 


POC MILES 1 


Number 


0 dp 


Block 4: POC Miles 


POC MILES 2 


Number 


0 dp 




POC_MILES_3 


Number 


0 dp 




POC MILES 4 


Number 


0 dp 




POC MILES 5 


Number 


0 dp 




POC MILES 6 


Number 


0 dp 




POC_MILES_7 


Number 


0 dp 




DATE 1 


Date 


D m Y 


Block 5 : Date 


DATE 2 


Date 


D m Y 




DATE 3 


Date 


D m Y 




DATE_4 


Date 


D m Y 




N_E_1 


Character 


20 


Block 5: Naure & 


N E 2 


Character 


20 


Explanation 


N E 3 


Character 


20 




N_E_4 


Character 


20 




AMT_C LA I M_ 1 


Number 


2 dp 


Block 5: Amt. 


AMT CLAIM 2 


Number 


2 dp 


Claimed 


AMT CLAIM 3 


Number 


2 dp 




AMT_CLAIM_4 


Number 


2 dp 




ALLOWED 1 


Number 


2 dp 


Block 5: Allowed 


ALLOWED 2 


Number 


2 dp 




ALLOWED 3 


Number 


2 dp 




ALLOWED 4 


Number 


2 dp 





APPR_OFFICER 


Character 


15 


Block 


6 : 


Approving 








Officer 




NUMBER 1 


Character 


20 


Block 


7 : 


Number 


NUMBER_2 


Character 


20 








FROM1 


Character 


20 


Block 


7 : 


From 


FROM 2 


Character 


20 








TOl 


Character 


20 


Block 


7 : 


To 


TO 2 


Character 


20 
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TABLE 5, cont. 



LEAVE 


Integer 


0 


to 255 


Block 

days 


8 : 


Leave 


HOURS 


Integer 


0 


to 255 


Block 

hours 


8: 


Leave 


DATE_8 


Date 


D 


m Y 


Block 

date 


8: 


Start 


DATE_9 


Date 


D 


m Y 


Block 

date 


8: 


End 


POC_OWNER 


Character 


1 




Block 

Owner 


9: 


POC 


POC_PASS 


Character 


1 




Block 9: 
Passenger 


CHECK 


Character 


1 




Block 


11: 


Check 


CASH 


Character 


1 




Block 


11: 


Cash 


PER DIEM REQ 


Character 


1 




Block 


12 : 


Per 



Diem Requested 

Record length is between 436 and 966 bytes. 

1000 records may use between 518000 and 1408000 disk bytes. 
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IV. EVALUATION PHASE 



The evaluation phase actually consists of three tasks, all focused on redefining the 
scope and feasibility of the entire project. The first phase is determining alternatives to 
the proposed solution. Secondly the feasibility of the project is re-evaluated based on the 
more detailed specifications which are now available to the designers. Finally all user 
requirements are evaluated within the scope of the alternative solutions. [Ref. 3:pg. 78] 
The evaluation phase will be effective only if a thorough understanding of the 
system requirements is achieved during the earlier phases of development. It was decided 
early on that using the OMNIS7 Integrated Development Environment would provide for 
the development of a graphical user interface which would facilitate learning by end 
users. The hardware requirements were determined to be of minimal concern as there is 
an ample supply of personal computers within the Administrative Sciences Department. 

It was decided that the choice of printer would be delayed until the TDS prototype 
was installed. This would allow the developer to evaluate the printers available in the 
Administrative Sciences Department and select the one best suited for the application. 

The application is designed using a structured approach. The only possible obstacle 
foreseen was the process of learning how to manipulate a very powerful database 
development environment. Otherwise it was still well within the realm of possibility for 
this project to be completed within the expanded time constraints. 
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development environment. Otherwise it was still well within the realm of possibility for 
this project to be completed within the expanded time constraints. 
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V. DESIGN PHASE 



The objective of the design phase is to develop a blueprint for the database and its 
associated applications. During this phase the development team establishes the database 
schema, the application sub-schema, formats for forms, reports, menus as well as the 
underlying logic. The mechanisms for update display and control are also determined at 
this time. After the database has been designed the team can design each application 
which consists of a collection of menus, forms reports and programs which meet the 
specific user needs. [Ref. 3:pg. 79] 

A. NORMALIZATION 

The goal of a logical database is to represent objects in the database using relations. 
The construction of user objects so that rows of data can be inserted, deleted, and 
modified without resulting inconsistencies or errors is paramount. The deletion anomaly 
occurs when one object is deleted and has the effect of deleting data from another object 
instance. The insertion anomaly occurs when data cannot be inserted into one entity until 
data is known about another entity. These conditions can cause serious problems in 
database design. The current design has all its relationships , as defined in Tables 1-5, 
in Boyce-Codd Normal Form. 
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B. PHYSICAL DATABASE DESIGN 



The four file formats involved in the Travel Database system are delineated in 
Tables 1 through 5. The key attributes (SSN, TRAVEL_ORD_NO, and 
STAN_DOC_NO) are noted with an asterisk. Their relationship to one another is 
graphically represented in Figure 2. In the OMNIS7 environment the unique key attribute 
is used to functionally define each relation, in other words, the remaining attributes of 
an object are associated in that file format to that unique key. As an illustration, only one 
record may have a particular SSN in the PERSDATA file. Likewise only one travel 
order may be linked to a unique Travel Order Number, although several travel orders 
may belong to one SSN. The relations are linked using OMNIS7’s record sequencing 
number (RSN) feature. 

The RSN feature takes care of the requirement to carefully arrange relational joins 
to avoid anomalies. For instance, if a personnel record is deleted, all of that person’s 
travel orders and travel claims are still available. Likewise, a travel claim or travel order 
can be deleted without affecting the associated personnel record. 
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VI. IMPLEMENTATION PHASE 



The final phase of the process is implementation. The details of the implementation 
depend a great deal on the DBMS being used. OMNIS7 is a very powerful program and 
nearly all of the requirements could be generated by the automatic code generation 
features of the development environment. This feature reduced the amount of effort 
required in the initial phase of implementation. Testing and installation are the final two 
stages of the implementation phase. [Ref. 3: pg 81] 

A. PROGRAMMING 

The goal of this phase is to construct the system as designed. The powerful nature 
of the OMNIS7 Development Environment did not require a great deal of custom coding 
(creating procedures in OMNIS7 parlance). Those custom procedures which were coded 
are included in Tables 6 through 9. The majority of the code is generated automatically 
by OMNIS7 and is therefore transparent to the developer. Procedures can be initiated for 
any field on any window or custom pushbuttons can be generated. The code written for 
this application facilitated report printing. 
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TABLE 6. CUSTOM PROCEDURES - PERSONEL WINDOW, W PERS DATA 

0. Initial Control Procedure 



Set Main File {FPERS DATA} 

Prepare for insert 

24. DD 1610 (pushbutton) 

Open window W_DD1610 

25. NAVPERS 1320 (pushbutton) 

Open window NAVPERS 1320 

TABLE 7. CUSTOM PROCEDURES - NAVPERS 1320 WINDOW, 
NAVPERS 1320 

66. PRINT NAVPERS 1320 (pushbutton) 

Set report name RD_NAVPERS 1320 

YES/NO message (Large size) (Print Standard Document Number 
[STAN_DOC_NO] for [FIRST_NAME] [LAST_NAME] ?} 

If flag true 

Prepare for print 
Print record 
Print totals 
End if 
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67. DD 1351 (pushbutton) 

Open window W_DD1351 

TABLE 8. CUSTOM PROCEDURES - DD 1610, W DD1610 

72. PRINT DD 1610 (pushbutton) 

Set report name DD_1610 

YES/NO message (Large size) {Print Travel Order Number 
[TRAVEL ORD NO] for [FIRSTJMAME] [LAST_NAME] ?} 

If flag true 

Prepare for print 
Print record 
Print totals 
End if 

73. DD 1351 (pushbutton) 

Open window W_DD1351 
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TABLE 9. CUSTOM PROCEDURES - DD 1351, W DD1351 

72. PRINT DD 1351 (pushbutton) 

Set report name DD_1351 

YES/NO message (Large size) {Print DD 1351 for [FIRST_NAME] 
[LAST_NAME] ?} 

If flag true 

Prepare for print 
Print record 
Print totals 
End if 



B. TESTING AND INSTALLATION 

The TDS was tested as a complete unit, although it consists of three separate 
modules. The system was installed on an Administrative Sciences Department PC and 
test data was entered. Some format errors were discovered on the data input screens, 
which were corrected immediately. Some errors were also found in connection with 
report output. Upon careful examination of these errors it was concluded that the existing 
printer could not support the application. A new printer was therefore procured and all 
errors were subsequently eradicated from the system. 
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VII. CONCLUSION 



The Travel Database System is currently installed in the Administrative Sciences 
Department Support Staff Office and is running in accordance with the design 
specifications. The users have indicated satisfaction with the system although it is not 
being used to the fullest. The result of maximizing the use of this system would 
undoubtedly be an increased productivity and a more uniform output from the office. 

The integration of an accounting system with TDS would further the department’s 
dependency upon these applications. This would improve user acceptance of the computer 
in the work space. The generation of future applications using OMNIS7 is highly 
recommended. 

Future upgrades to the existing system can be readily determined as well. A series 
of reports highlighting accounting data and travel as well as further automation of data 
retrieval are just two examples. 
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APPENDIX A. 

USER’S GUIDE TO THE ADMINISTRATIVE SCIENCE DEPARTMENT’S 

TEMADD DATABASE SYSTEM 



A. INTRODUCTION 

The purpose of this manual is to familiarize the user with the Administrative 
Sciences Department’s TEMADD Database System (TDS). The system is linked through 
a series of windows or, for more experienced users, a series of pull down menus. The 
system is designed to be easy to use but does require some familiarity with Microsoft 
Windows and the use of a mouse. 

B. GETTING STARTED 

Before running TDS, the OMNIS7 Integrated Development Environment and 
Microsoft Windows must be installed as specified in their respective user’s manuals. The 
application file TRAVEL. APP must be loaded onto the hard drive. The hard disk storage 
space required is 4 MB. The data files can be maintained on a floppy. To run the 
application from the prototype software the user must first initialize Microsoft Windows. 
The following steps will guide the user to the PERSONNEL window. 

1. From PROGRAM MANAGER select the OMNIS7 Icon and initialize the 
OMNIS7 Integrated Development Environment. 

2. From OMNIS7 Bar Menu select FILE. Select OPEN APPLICATION from the 
pull down menu. See Figure A-l. 
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$>en Application... Ori+O 



£\csc Application 
&av« AppHtMimt 
Saye A Copy As... 


Password... 




Chong* Oafln Files... 




Hepor* Ocsltnatifm... 




Poye Cetyp... 




M*™** 


► 


Lang Menus 




E«H 




A£oiri Omni s 7.~ 





Figure A-l. Initialization Pull Down Menu 
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3. Highlight TRAVEL. APP trom the pop-up menu and press < enter > . See Figure 
A-2. 



Selrrt application 



have Lapp 



Fi edM 

D vector jr. c:\omis\thesis_a 



E jkr 







directories: 



ii 
i— -l 

m 

l-e-I 



0 Single 



Figure A-2. Select Application Pop-Up Menu 
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4. Select DESIGN from the OMNIS7 bar menu. Next, select MENU FORMATS... 
from the pull down menu. See Figure A-3. 



a 








0 till fit. f 


D 


le £dH | 


'I'Mtjtl , 


ytJimes Help 





tJlc Formats.,, 
window Format*— 
Qcport Formats... 



Mi iiii I «fiii it 



Search Formats... 



List Field Names FB 



Dose Jap Window 
Close Other Windows 
Close AH Windows 



Figure A-3. Design Pull Down Menu 
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5. Highlight TRAVEL from the pop-up menu and Select the INSTALL option from 
the buttons on the right hand side of the pop-up menu. See Figure A-4. 



Omuls / 



tile lQ» UMUtte* Help 



n i I orr »* 



Select Menu 




fl 



Figure A-4. Menu Formats Pop-Up Menu 
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6. The TRAVEL menu will now be installed in the bar menu. 

7. Highlight the TRAVEL selection from the bar menu. The PERSONNEL option 
will be highlighted. See Figure A-5. 




Figure A-5. Travel Database Pull Down Menu 
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8. Press ENTER. The PERSONNEL entry form will come up on the screen. See 
Figure 6. The TDS is now ready for data entry. 



ytfbes fitmnaods TRAVEL grig 



« tm i 



LAST NAME TOST NAME MDOLEMTWL 



POSTON 



1 1 1 


1 


ISM MJK 


ffitVfCE 


1 1 [ !□ 


1 1 


OFFICIAL ST A HOH 




1 





I 1 

OACAMZATMMAL ELEMENT rHOIKIWMBHl 



CLEAMHCt 

I' I 



MAILING ADDRESS 

STKEFJ ADCFESS 



CITY 



STATE 

□ 



ZPCCOE. 



hl> h-lu 



I HH 



Figure A-6. Personnel Data Entry Window 
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C. PUSH BUTTONS 



There are five push buttons common to all four data entry windows, the 
pushbuttons which are unique will be described in the data entry portion. 



1. FIND. The FIND button will initialize a search on the file until the designated 
record is found. If the record is not found the user is told that no match exists. 
To use this feature place the mouse over the blue FIND button and depress the 
left mouse button. The cursor will be automatically in the data entry field against 
which the search will be conducted. Enter the value (name, travel order number, 
etc.) which is the unique value of the record you wish to find and press ENTER 
or press the OK push button. If the record exists it will be displayed. If you are 
told that the record does not exist, check the entry and try again. 

2. EDIT. The EDIT pushbutton will prepare the record which is currently displayed 
for editing. The cursor will tab between fields, highlighting the active field. The 
user may also highlight the field by placing the mouse arrow directly on the field 
which is to be edited and pressing the left button. When the desired field is 
highlighted the editing may be completed. Once all of the desired fields are 
edited, the user must press the OK button. 

3. INSERT. The INSERT pushbutton places the cursor in the first field into which 
data may be entered. Once a record is completed the user must press ENTER or 
OK. 

4. OK and CANCEL. These pushbuttons are active during the EDIT and INSERT 
operations and are used to end the process. OK allows the data to be written to 
the file. CANCEL simply ends the data entry process without writing to the data 
file. 



D. PERSONNEL DATA FORM 
1 . Data Entry 



1 . Move the mouse over the INSERT pushbutton. After the button has been pressed 
the cursor will be in the LAST NAME data entry field. 
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2. Enter the required data and <TAB> to the next field. Once all the required data 
is entered press the OK button in the same fashion described in step one. 

3. To insert another record repeat step one. 

2. Find\View\Edit Record 



1. Position the mouse over the find button and depress the left mouse button. 

2. The cursor will automatically move to the LAST NAME field. 

3. At this point, if the last name is known, enter it and press < ENTER >. The 
desired record will appear in the data entry form. 

4. If the last name is unknown, enter the first initial of the last name and press 
< ENTER >. 

a. At this point, the first record beginning with the desired letter will appear. 
To scroll through the records position the mouse over the NEXT 
pushbutton and click with the left mouse button. Each click will put the 
next record into the data entry window. Continue clicking until the desired 
record is found. 

5. To EDIT the record simply position the mouse over the EDIT pushbutton and 
depress the left mouse button. The first data entry field will be highlighted. To 
move from field to field press <TAB> . 

6. Edit fields as desired. When the editing is complete position the mouse over the 
OK pushbutton and depress the left mouse button, or press < ENTER > . 

3. Delete Record 



1. Find the Personnel Record which is to be deleted. 

2. Position the mouse over the COMMANDS selection from the bar menu. 

3. Highlight DELETE. 
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4. A confirmation window will pop-up in the bottom left hand corner of the screen. 
If the record is to be deleted, select "YES." If a different record is to be deleted, 
select "NO" and find the proper record. 

5. This option will permanently remove the selected record from the data base. It 
is recommended that extreme caution be used when exercising this option. 

4. DD 1610 Data Entry Form 

a. Data Entry 



1. Initiate the DD 1610 Data Entry form the Personnel Data entry Form. The 
method for doing this is as follows: 

a. Once the desired Personnel Record has been entered or found position the 
mouse over the DD 1610 pushbutton and depress the left mouse button. The 
DD 1610 Data Entry Form will come up on the screen with the personnel 
data fields already filled. 

2. In order to initiate a new DD 1610, position the mouse over the INSERT 
pushbutton and depress the left mouse button. The database is now ready to 
accept a new record. 

3. The cursor will be positioned in the TYPE ORDER data entry field. As the data 
is entered, tab from field to field. 

4. When all the required data is filled in press < ENTER > or position the mouse 
over the OK pushbutton and depress the left button. 



b. Find\View\Edit Record 



1. In order to find a DD 1610 for viewing or editing position the mouse over the 
FIND button and depress the left mouse button. 

2. The cursor will be positioned in the TRAVEL ORDER NUMBER field. Enter 
the travel order number which is associated with the record to be viewed or 
edited. Press < ENTER > and the desired record will be brought to the screen. 
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3. To EDIT the record, position the mouse over the field to be edited and depress 
the left mouse mountain. <TAB> between fields and complete the required 
editing. When all the editing is completed press < ENTER >. 



c. Delete a Record 



1. If a record is to be deleted, it must be brought into the data entry form as 
described in the Find\View\Edit section. Delete as described in the Personnel 
section. 

2. Exercise extreme caution when using this option. The record will be permanently 
removed from the database if the option is completed. 



d. Print a DD 1610 



1. Complete the data entry for the DD 1610. 

2. Position the mouse over the PRINT DD 1610 pushbutton. Depress the left mouse 
button. 

3. A confirmation window will appear asking the user to confirm the name and 
travel order number. 

4. If the information in the confirmation window is correct, select YES. If not, 
select NO. 

5. Once the form has been printed, position the transparency over the data sheet and 
create a copy. This is the original. 



e. NAVPERS 1320 

The procedures for manipulating this form are the same as for the DD 



1610. 
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/. DD 1351 

The procedures for manipulating this form are the same as for the DD 
1610 and NAVPERS 1320. 
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APPENDIX B 
REQUIRED FORMS 



Figure B-l DD form 1610 

Figure B-2 NAVPERS 1320\16 

Figure B-3 DD form 1351 
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REQUEST AND AUTHORIZATION FOR TDY TRAVEL OF DOD PERSONNEL 

(Reference: Joint Travel Regulations) 

Travel Authorized as Indicated in Items 2 through 21 



1 DATE OF 
REQUEST 



2. NAME (Last. First. Middle fnutaJ) 



BEOUEST FO* OfHClAl TRAVR 



3. POSITION TITLE AND GRADE OR RATING 



4. OFFICIAL STATION 



3 ORGANIZATIONAL ELEMENT 



«. PHONE NO. 



7. TYPE OF ORDERS 



I0o APPROX NO OF DAYS OF 
TDY (Including travel time) 



0 SECURITY CLEARANCE 



9 PURPOSE OF TDY 



h. PROCEED O/AfPa/c) 



1 I. ITINERARY 



d] VARIATION AUTHORIZED 



MODE OF TRANSPORTATION 



COMMERCIAL 



GOVERNMENT 



privately owned conveyance (Check one) 



RATE PER MILE 



a AS DETERMINED BY APPROPRIATE TRANSPORTATION 

officer (Overseas Travel only) 



1 1 more ADVANTAGEOUS to GOVERNMENT 

□ 



MILEAGE REIMBURSEMENT AND PER DIEM LIMITED TO CON 
STRUCTIVE COST OF COMMON CARRIER TRANSPORTATION ft 
RELATED PER DIEM AS DETERMINED IN JTR TRAVEL TIME LIMITED 
AS INDICATED IN JTR 



3 □ PER DIEM AUTHORIZED IN ACCORDANCE WITH JTR 

I 1 OTHER RATE OF PER DIEM (Spec#/) 



14. 


ESTIMATED COST 




13. ADVANCE 
AUTHORIZED 


PER DIEM 


TRAVEL 


OTHER 


TOTAL 




s 


s 


s 


s 


s 



7. REQUESTING OFFICIAL (TilJeanJ signature) 



16 approving OFFICIAL (Title and signature) 



AUTHORIZATION 



z 

JO 


APPROPRIATION 

ANO 

SUBHEAD 


OBJECT 

CLASS 


BUREAU 

control 

NUMBER 


SUB 

AUTM 


AUTHORTZADON 

ACCOUNTING 

ACTIVITY 


TYPE 


TRAVEL OROER 
(Tango)no 


COST CODE 






































- 



















20. ORDER AUTHORIZING OFFici AL(Tltle and signature) OR authentication 



2 1 DATE ISSUED 



22 TRAVEL ORDER NUMBER 



DD i^SITt 1610 •'* 0.01 LF O.a. 7702 



NAVY OVERPRINT - JAN 1071 



Figure B-l. DD form 1610 
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TEMPORARY ADDITIONAL DUTY (TEMADD) TRAVEL ORDERS 



1. FROM. 




2. STANDARD DOCUMENT NO 



4 . TANGO NO. 



5 SSN/DESIGNATOR 



6 DATE 



7 REF (A) 


8 , r— , 

INDIVIDUAL GROUP 

1 — 1 TRAVEL 1 — 1 TRAVEL 


9 PROCEED ON OR ABOUT 10 AUTHORIZED PROCEED ON OR 11 APPROXIMATE NUMBER OF 

ABOUT D \YS 


12 ESTIMATED DATE OF RETUFtN 


13 ITINEFIARY (Activity activities ana Place places indicated below) 


| | TEMADO Q3 TEMAIXXXW Q TEVUJXHKS 


15 REASON FOR TRAVEL 


16 I 1 AUTVOftiZED VISIT SUCH ADDITIONAL 

1 — 1 PLACES AS MAY BE NECCSSAflY 



1 7 FISCAL DATA ACCOUNTING CLASSIFICATION 



APPROPRIATION 


OBJECT 


BU CONT 


SUB ALLOT 


AUTHORIZED 


TYPE 


PROPERTY 


COST COOE 


SYMBOL AND SUB-HEAD 


CLASS 


NUMBER 


NUMBER 


ACCTG ACTY 




ACCTG ACTY 




(1) 


(2) 


(3) 


(4) 


(5) 


(6) 


(7) 


(8) 


(9) 


(7 SYM) 


(4 SYM) 


(3 SYM) 


(5 SYM) 


(1 SYM) 


(6 SYM) 


(2 SYM) 


(6 SYM) 


(12 SYM) 


18 






ESTIMATED COST 






10. CUSTOMER IDENTIFICATION COOE 


TRANSPORTATION 


PER DIEM 


MISC EXP. 


TOTAL 








$ 




S 


j 


l 


$ 









20 ITEM. (Use applicable item number* as sAown on reverse pde of this term) 



Report to a Disbursing Officer wrthin 10 bays after compteuon of travel to settle your travel expenses * 



21 ADDITIONAL COMMENTS AND INSTRUCTIONS 


22. SECURITY CLEARANCE: 
fT IS CERTIFIED THAT YOU 
HOI n A 




RASFD 


OOMP1 FTFn 


BY 


(PIUS 


YEARS SERVICE) 


23 AUTHENTICATING SIGNATURE 


24 TRANSPORTATION REOUEST MAC TRANSPORTATION AUTHORIZATION FURNISHED 


25 COPY TO (Include Operating Budget fund manager in all cases) 



NAVPERS 1320 16 (Rev 11-87) S N 0106-LF-0 13-2082 



Figure B-2. NAVPERS 1320/16 
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S/N 0102-LF-0 13-2803 



(Complete by typewriter. Ink, or boU 
potnt pen (PRESS HARD) do not lor penal) 



TRAVEL VOUCHER OR SUBVOUCHER 



READ PRIVACY ACT STATEMENT ON REVERSE PRIOR TO COMPLETING THIS FOR K1 



LAST NAME FIRST NAME MlOOLE INIT LAL (Print/ T rprf 



CHECK MAJUNO ADORE SS (Include ZIP Code f 



OftADE/RANK SSN 



ORGANIZATION AND STATION - 



DUTY PHONE NO 



TRAVEL ORDERS (P«r«rvA SO No . Itsumg Hq . Dmie) (Include emending or den) 



PRIOR TRAVEL PAYMENTS OR ADVANCES UNDER THESE ORDERS (Amount. DO Pour her No . Dole Received. Piece pod. 
o' DO Station No. If name, to ttetel 




1 fTlNE RAR Y (See Item 23 Jor Symbols) 


2 

COST 

Of 

LOOGINQ 


"37 NUMBER 


4 

POC 

MILES 


OATE 
19 


IOCAI TIME 
(24 Homr dock) 


PLACE 

(Home. Office , Bate. Actinty. City 
end Stele, City end Country, etc ) 


M 


1 % 


vr me 




GOVT / 
/o€D ’ 


OPEN 

MESS 




OEP 












APR 




1 








4 








DEP 








ARR 












/j 






COMPUTATIONS 




DEP 
















ARR 












y 










OEP 












/ 




: ; 






ARR 












y 










oe p 












y 










ARR 






















DEP 
















: yy-y; 






ARR 












yy 










DEP 












y , 










ARR 












y 









FOR DO USE ONL Y 



DO VOUCHER NO 



SUBVOUCHERrO 



PAID BY 



REIMBURSABLE EXPENSES/CHARGE FOR DEDUCTIBLE MEALS * (See Item 2*1 



NATURE AND EXPLANATION 



AMT CLAIMED 



SUMMARY Of PAYMENT 



Per Oem 



Actual Expense 



9 Lo*n diWinct l e Vphoae cilh ere cmified is Krcnwy m the 
truer m ot the C 



APPROVING OFFICER 1 3 1 VSC MOe) 



Milage ex T t ansp Allowance* 



Reimbursable Expanses 



TR SA4TA SA4T8 ((/none, to note) 



Total Entitlement 



Less Previous Payments 



Less Voucher Deductions 



Amt Charged lo Acctg Os 



11 PAYMENT DESIRED 

□ CHECK 



□ CASH 



8 LEAVE STATEMENT 



Noun tak*n berwrMn 



□ PER DIEM REQUESTED 



t POC TRAVEL 



□ OWNER/OPERATOR (See Item 22d) 



□ PASSENGER 



13 BAS RATE 



PENALTY T>* p*na*y »or rrWufty m»k^g • ft*** clem « A MAXIMUM FINE Of JlO.OOno* MAXIMUM IMPRISONMENT OF S YEARS. OR BOTH (VS Code, Title 19. Section 297 ) 



^ I Vreby cLum wiy imouni due me TV natementi on luce, reverie. 

•tt*ched tre true «r>d com pine Piymeru o» CTedti Kri ixx been reserved 



14 SIGNATURE Of CLAIMANT 



OATE 



IS ACCOUNTING CLASSIFICATION 



1« COLLECTION DATA 



17 COMPUTED BY 


18 AUOITEO BY 


19 TVLRCROPOSTEO 
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